Nat Friedman, CFO

Tectonic: “Friedman recalls going to the ATM after the $2 million was deposited and getting a statement. ‘It ran off the edge of the page!’ He then tried to transfer the $2 million from one account to another through the ATM, which the system couldn’t handle. Eventually – with a good queue growing behind him – Friedman moved the money in $500 000 increments. A week later they hired a CFO, who banned them from moving millions of dollars around through the ATM.”

Comments Off on Nat Friedman, CFO

Motorola: Let’s standardize Linux, Java

ZDNet Asia: “Unified standards in next-generation Linux-Java mobile applications will need to be established, as the cellular and IP (Internet Protocol) worlds collide in the future, says a senior executive from Motorola.”

Comments Off on Motorola: Let’s standardize Linux, Java

Open-source Java and compatibility in the Java world

Sun is worried about compatibility in a world where Java is open source. I can’t say I blame them, and I say this as someone who spends a majority of his time thinking about compatibility in the Linux world, where we’ve managed to hold it together but still have a lot of work to do to match the relative consistency of the Microsoft alternatives (Windows and .NET, among others). After all, a platform is useless if there’s not a single, standard way for developers to target it.

Question is: Does open source inherently lead to compatibility problems? Hardly. How many incompatible versions of, say, Apache are there? Or the Ps of the LAMP stack (Perl, PHP, Python)? Or MySQL? GNOME? KDE? BIND? CUPS? The only reason “Linux” and compatibility often come up in the same breath is because the term is used to describe so many different things. Yes, “Linux” has compatibility issues if you’re comparing Red Hat, SUSE, and Debian, but the actual “Linux” used by each of these “Linuxes” (that is, the Linux kernel) have few if any compatibility issues. It’s more the bits around the edges, like slightly different versions of core components with slightly different ABIs or APIs, not to mention the independently developed subsystems for configuration etc., that lead to the compatibility issues. If anything, the fact that the various Linux distributions share so many of the same open source components makes them far more compatible than the various implementations of UNIX ever were.

James Gosling, the father of Java, highlights JavaScript as an example of the situation they’re trying to avoid in a recent podcast with Dan Farber. Today, he explains, there are dozens of AJAX toolkits, and the main reason for this is the need to paper over incompatibilities between the various JavaScript implementations.

He’s absolutely right. If anything, though, the JavaScript situation is a good example of what might have been if we knew as much about the power of open source in setting standards in the 1990s as we know today. There are numerous JavaScript implementations today because there wasn’t a de facto standard implementation developers could just use when they needed one way back when (like there was with Apache etc. and wasn’t with some of the problematic “Linux” technologies like configuration management). What if there had been an open source JavaScript all along that became a de facto standard like Apache did? Would the AJAX world look any different today?

Ironically, then, Java looks a whole lot more fragmented on its current trajectory as the various open source efforts (Apache Harmony, GCJ, GNU Classpath, etc.)—which exist only because the de facto standard implementation isn’t open source—mature and are more tightly integrated into the Linux distributions.

So, what lessons does Linux have to offer Sun as it contemplates the future of Java and, more to the point, how to open source it? First of all, far from being a surefire path to turning Java into a veritable tower of babel, open source could actually help promote compatibility in the Java world. For one thing, if Sun’s Java implementation was open source, history shows there would be no need for another implementation. Case in point: Remember the other Harmony project?

Secondly, what’s in a name? Absolutely everything. It’s entirely possible to open source Java without diluting the Java brand and the compatibility guarantees that brand promises. Most famously, this strategy has worked very well for Red Hat—Red Hat’s platform is open source, so you can fork it, but you can’t call the result “Red Hat”, which preserves the compatibility guarantee a successful platform requires.

It’s not too late, but we’re rapidly approaching a time when it will be. For one thing, the open source implementations are getting better, and once the genie is out of the bottle, it’s damned near impossible to get it back in (see, again, JavaScript). As I said the other day, “open source Java” isn’t so much about licensing as it is about ubiquity, though licensing can get in the way of ubiquity. We’re almost there. Let’s take the final step we need to take to make Linux/Java as well integrated as Windows/.NET.

apt-get install java (literally)

Simon Phipps: “Yes, you can now apt-get install sun-java5-jre and have it install without fuss on Debian and Ubuntu.”

Great news. We’re one step closer to a Java/Linux combo that’s more than just Java bolted onto the side of Linux (admittedly, there’s still a bit of that here, though at least it’s attached with standard componentry now rather than the old bubble gum and bailing wire).

Why is tighter integration important? Because the alternative, namely Windows and .NET, offers a tightly integrated combo that “just works”. The more a developer has to do (like, say, ship a bundled runtime because that runtime isn’t guaranteed to be available on a key platform), the more attractive the alternative looks.

The real question is: Will this be enough? I’ve long contended that open-source Java is a red herring—the real challenge for Java on Linux is ubiquity, not licensing, and licensing is really only an issue because it gets in the way of ubiquity. Time will tell if this step represents the boost Java needs to become to Linux what .NET is to Windows.

I don’t know though. For that to happen, the major Linux distributions have to not just add Java to the menu of available software, they have to add Java to the default configuration (much as Perl and Python are default components today), and I just don’t see Red Hat, Debian, or Ubuntu doing that till Java is open source. Still, I’m optimistic we’ll get there. Question is, will we get there in time?

P.S. – How about making some of the Java platform components available via APT too? If I’m developing an application that uses, say, JavaMail, I have to go to the web, download it, figure out that it depends on the JavaBeans Activation Framework (JAF), download that, set up my classpath appropriately depending on where I downloaded them, etc. It would be great if I could just apt-get install javamail and have exactly the environment I need without additional effort.

Don’t miss it

Andreas Barth: “We expect to release Etch as planned in the beginning of December 2006.”

Excellent, excellent news. I cannot overemphasize how important it is that Debian release Etch on time. Between this, Ubuntu’s commitment to LSB certify Dapper (a huge step toward enabling ISVs to target Debian and Ubuntu with a single certification), and recent industry events, this is shaping up to be Debian’s breakout year. Significant delays or even uncertainty in the Etch schedule, though, changes that pretty substantially.

Linux Standard Base (LSB) 3.1 released

I’ve been rather quiet lately, but that’s because I’ve been busy helping put the finishing touches on LSB 3.1, which was released early last week. New in LSB 3.1 are the integration of the ISO standard LSB Core (ISO/IEC 23360) and the addition of the LSB Desktop platform above the core (which stops at the desktop toolkits in 3.1, i.e., GTK and Qt, but that will move up the stack to encompass more of GNOME and KDE in 3.2 and 4.0). LSB 3.1 also lays a solid foundation on which to build LSB 3.2 and 4.0. Key milestones here include alignment of the LSB roadmap with the roadmaps of the major Linux distros and more direct participation of the key stakeholders in the standard (distro vendors, ISVs, and upstream project maintainers). Much, much more to come on these points as soon as I’m fully recharged.

In the meantime, I’m pleased to report we had a very successful launch last week. The release was supported by a who’s who of the Linux industry: Dell, HP, IBM, Linspire, Novell, RealNetworks, Red Flag, Red Hat, Ubuntu, and others. Importantly, no fewer than ten major Linux distributions have committed to LSB 3.1 certification, including upcoming versions of Asianux, Linspire, Mandriva, Red Hat Enterprise Linux, SUSE Linux Enterprise Server and Enterprise Desktop, Sun Wah Linux, Turbolinux, Ubuntu, and Xandros. In short, if you’re an application developer, and you want to easily target all of the major Linux distributions, LSB 3.1 is a great way to do it.

More details here: BusinessWeek (and dozens of others via the Associated Press, including ABC News, the Boston Herald, Forbes, FOX News, MSNBC, the San Francisco Chronicle, and the San Jose Mercury News), eWEEK, InformationWeek, InfoWorld (and others via the IDG News Service), Slashdot (twice, here and here), and many other places.

What does it mean to be a “paying customer” in Web 2.0?

Stephen O’Grady is wondering whether Google Calendar finally represents a solution to Redmonk’s calendaring woes. The downside?

Well, as Ian learned recently, you’d apparently have to be a “dipshit” to trust free services with “CRUCIAL” data (apparently your personal emails and such aren’t crucial). While I don’t buy that argument at all, nor do I fully trust services that I’m not paying for. That, more than any other reason, is why I believe Google ultimately will roll out for-pay services: folks like me are more than willing to pay for them, if the price is right.”

Stephen has a great point, and I agree wholeheartedly. I’m not going to fully trust a service provider unless there’s some financial incentive for them to provide reliable service—in other words, I’m a paying customer who can take his business elsewhere if the service isn’t up to par.

But am I not a paying customer of Google already? As Steve Gillmor has said time and time again, Google makes money (boy, does it make money) by selling my attention to its advertisers. Just because I’m not forking over $59.95 per year or whatever directly to Google doesn’t mean I’m not paying for the service they’re providing me.

To my mind, this is a whole lot like ABC vs. HBO. ABC makes money when I watch Lost, just like HBO makes money when I watch The Sopranos. They just have different ways of doing it—in other words, different business models.

In earlier posts, I opined that perhaps the software-as-a-service model isn’t viable if the service providers aren’t willing to make quality of service guarantees, you know, like “we won’t lose all your stuff if you put it here”.

Now that I think more of about it, though, it’s more accurate to say that it’s the advertising business model that isn’t viable. I don’t see too many people worried that they’re going to wake up one morning to find all their data is gone from Salesforce.com.

So, can Gmail, Google Calendar and related software-as-a-service offerings really only have quality of service guarantees with a subscription business model? For Google’s sake (which, after all, derives 95%+ of its revenue from advertising), I sure hope not.